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GOOD NEWS FOR THE 8 

The past two or three years many PDP-8 users have been expressing the feeling 
-that DEC was ignoring the 8 family in favor of other lines such as the 11. 
Investigation into the reasons has suggested that one of the reasons for this 
situation was the fact that marketing of the 8 family has been fragmented 
among a number of product lines. In each product line the 8 was a secondary 
concern so it received relatively little support and what support there was 
tended to be poorly coordinated between the separate product lines sometimes. 
Recently there have been rumors that DEC was finally recognizing this situation 
and that something was going to be done to rectify it* Although the formal 
announcement bad not yet been made at Newsletter deadline time, I was able to 
obtain the following brief announcement because it will not reach you until 
after the official announcement is made: 

"The new PDP-8 Marketing Group was announced at the Spring DECUS Symposium. By 
concentrating OEM and user resources, Digital management expects to provide 
better support for PDP-8 customers. As of July 1, the new group, composed of 
PDP-8 elements of OEM, LDP (Lab), IPG (Industrial) and EDU (Education) product 
lines, will conduct all OEM and most end user PDP-8 business for DIGITAL. Jim 
Willis, rT liv PDP-8 Product Line Manager also performs that function for the new 
combined product line." 

As many of you know, Jim has been very cooperative and helpful with the users 
and has supported the 8 family very well. 

The indications are that this development is accompanied by increased funds 
for software development. This fact and the transfer of some former 8 software 
development people has resulted in a substantial re-staffing of 8 software de- 
velopment. We will have a chance at the DECUS meeting to Judge better ao^ that 
effort is going, but early contacts suggest we will see a revitalization and 
increased level of activity in this area. 
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SURVEY RESULTS 

The responses to the "User Input to DEC Software Planning" survey distributed 
with the last Newsletter have been coining in steadily. As of the Newsletter 
deadline 102 responses had been received. The responses range from simple 
check offs of answers to three page expositions. Copies of the responses are 
being reviewed by the PDP-8 product line and the PDP-8 software development 
group. 

The meat of the responses is in the many and varied comments. It is not possi- 
ble to summarize all the comments here but I will list the current count of the 
question check offs to give some idea of how it is going. 

1. Operating System Development 71 
Language Development 29 

2. "OS/8" Type Single User System Development 30 
"RTS-8" Type Multi-Task System Development TO 

3. RTS-8 FORTRAN IV Development k8 
New BASIC Development 25 

Other: 

FOCAL 8 

PL-1, PL-M (etc.) 5 

PASCAL k 

APL 3 

Business Languages 6 

RPG 2 

ALGOL 2 

5- Accept Fewer Supported Configurations 

Yes 71 

No 26 

NEWSLETTER DEADLINE 

The final deadline for camera-ready copy for the next Newsletter is June 25, 
1976. See Newsletter #15 for deadline details. 

"NAME THE S.I.G." 

Jim VanZee sent along an idea for a new name for our Special Interest Group 
(see reque. t in last Newsletter). He suggests that besides the obvious 
"12 Bit SIG : ' we might like a group or newsletter name of "BYTE AND A HALF" 
(Maybe "BYTE 'IM IN HALF" - Jim points out the interesting logo ideas that 
leads to). Let's have more ideas ana -~" z'ms. Computer people seem to be 
very good at this sort of thing. 

NEWSLETTER POLICY 

At its April meeting the DECUS U.S. Executive Board formally adopted its policy 
regarding non-commercialization of DECUS publications. Announcements of soft- 
ware and other items for sale are generally limited to technical information as 
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opposed to obvious promotional material and no prices are allowed except where 
they are clearly nominal to cover reproduction and handling. Enforcement and 
interpretation of the policy is basically in the hands of newsletter editors and 
SIG chairmen. The policy will have little or no impact on our Newsletter as it 
is essentially the policy I have been following. If you need a copy of the 
official policy, contact the DECUS office. 

EUROPEAN OS/8 SIG 

Ernst Lopes Cardozo writes to say that the European group will try to channel 
its inputs to the Newsletter through Lars Palmer on the new deadline schedule. 
Ernst supports expanding the scope of the SIG to all 12 bit issues, hardware 
and software. I expect this step will be formalized at the May Symposium in 
Atlanta. 

Ernst reports that the Dutch LUG-8 has organized a few "tutorial days" in the 
past. An expert would give a one-day course en TECO, (ROG-) ALGOL, 8BAL, etc. 
He has been asked to organize some of these user-for-user courses during the 
day immediately preceding the next DECUS Europe Symposium in September. He 
inquires about what we do in the U.S. Most of this sort cf thing in the U.S. 
has been informal - mainly individual sessions during the symposium itself. 
I wonder if there is any sentiment in favor of separate get-togethers isolated 
from the multi-parallel sessions at the U.S. Symposium? Maybe we should be 
considering sessions either before or after the symposium or perhaps completely 
separate meetings - maybe on a regional basis where the costs could be mini- 
mized. This sort of thing would tie into a development of 12 Bit Local User 
Groups in the U.S. and elsewhere. We certainly have enough members (about 1600 
worldwide) and tuere are already many precedents for LUG meetings as well as 
totally separate U.S. level SIG meetings. What do you think? Will you help 
put it together the first time? I can help with names of other SIG members in 
your area but I can*t do the main work of organizing and running sessions. 

HASSLE STATISTICS PACKAGE 

Lars Palmer has written about on-going work on his STAT package (DECUS 8-660) 
which he expects to submit to the library before long. The package is a 
statistics package that provides a fairly extensive set of capabilities in a 
nice combined package that takes advantage of several features of OS/8 FOR- 
TRAN IV such as overlays. 

FORMS AND OTHER INFORMATION FROM LARS PALMER 

Lars Palmer sent along some information on his OS/8 FORTRAN II program "FORMS" 
which converts a PDP-8 with CRT (particularly a VT05) into an intelligent form 
filling terminal with a "Key to Disk" type function. Lars does not plan to 
submit this program to DECUS but if anyone is interested they can contact him 
directly at: AB Hassle, Fack, U31 20 MOLNDAL 1, SWEDEN. 

Lars also mentioned some routines he has available separately that might be 
of interest. KSORT (from DECUS 8-660) for sorting and transforming data, 
FILSIZ which will determine in an OS/8 FORTRAN IV program what the size of files 
that have been specified at run time is, LESQ (from DECUS 8-66l) which gives 
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a flexible way to do least squares curve fitting, and MACRO which is a tape 
with several useful TECO macros for listing directories and files. This last 
includes a scheme for a BASIC program which is hooked up with the CCL DATE 
command to create a file with the current date in it for a TECO macro to use in 
inserting the current date in files as the first line. Also in this package is 
some material to use with Tom Mclntyre's MEDIA management package (i.e., com- 
bined sorted directories of all your tapes, etc.). 

NOTE ABOUT TIME SHARING FROM BILL HAYGOOD 

Bill has written to say he has completed work on his multi-user time shared 
operating system which runs OS/8 as a job on multiple terminals. He has modified 
ODT and some of the device handlers for efficient time sharing under OS/8. 
The present system is a specialized one which runs on a U.S. Postal Service 
dual PDP-8e configuration. Bill says that performance is dependent upon what 
OS/8 program you are using. EDIT is slowed somewhat but TECO runs well. The 
system includes "down line bootstrapping" of the slave machine from the host. 
At present he is running 05/8 at two terminals and special CAI programs on the 
other five. Bill says that the system will soon get an additional 96 K of memory 
and a special interface to give a 123K PDP-oe. He plans to develop the software 
for this configuration so OS/8 can still run as a job. 

If anyone is interested in seeing Bill's system in operation they can contact 
him. He says he cannot handle much correspondence but if anyone is going to be 
in Salt Lake City he would be glad to show off the system. Bill feels he has 
solved some very sticky problems and most of DEC's OS/8 programs will run un- 
modified, even BUILD works correctly. If you want more information, Bill's 
address and phone are: Computer Services Co. , 370 ^ Ridgecrest Drive, Salt Lake 
City, Utah 8Ull8, his phone is: (801) 966-lklk. 

SCIENTIFIC SUBROUTINE PACKAGE UPDATE 

Lars Palmer has contributed some work to improve the S.S.P. The DECUS library 
now has the original OS/8 submission with complete comments on five DECtapes. 
It now has, in addition, a compressed version. Lars rf oved all comments making 
it possible to squeeze the package on two tapes. I rearranged the tapes so that 
all routines that require an FPP with double precision option (i.e., DOUBLE 
PRECISION is used) on one tape and all the rest of the package on another. Thus 
you can have the entire non-double precision library available on a single tape 
(about 270 files!). This also allows you to order just one or two tapes if 
you have sufficient documentation. If you can't wait for the S.S.P. to appear 
in the next library catalog then contact the library* but please don't bug them 
unless you really need it. They have been hard pressed lately with personnel 
shortages . 

FLAP 

My note about FLAP in the last Newsletter drew several responses. Hans Goebel 
says that as of last October a version of FLAP that runs under OS/8 and the 
FFP Support Package were still being distributed for the FPP- 12. He has found 
the Support Package quite useful and has adapted the random number generator 
and an interrupt mode driver for a second terminal to RALF. Lars Palmer writes 
that the version of FLAP he received still requires the FPP hardware. As some 
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of yoa knew, FLAP and HALF are alternate conditional assemblies of the same 
source. HALF was modified to work without the FPP hardware back when RTPS FOR- 
TRAN was re-written to run without the FPP and was re-designated OS/8 FORTRAN IV. 
It would appear that the version of FLAP still "being distributed came from a 
version of the sources from about four years ago. I have corrected some errors 
that have crept into the sources since then so that I can generate an updated 
version of FLAP which takes advantage of a number of improvements put in for 
RALF and, of course, the new version does not need the FPP to assemble programs. 

Professor Zimmerman indicates that he has used FLAP but that the version he 
received had a limited symbol capacity (100 or 2CQ symbols). I have not de- 
termined if the new version is any "better but I think it may be. Full use of . 
extended memory is not made by the FORTRAN IV compiler and RALF, however, so 
FLAP probably does not make good use of extra memory either. 

Brian Converse says that he and Larry Alber have both been interested in FLAP 
but that they both have experienced a series of problems trying to get the 
distributed versions to work successfully. Brian WOuld like any information 
available on timings for the ATX and XTA instructions on the FPP-12 and the 
FPP-8A as he is very concerned with working on 12 bit data as fast as possible 
and the information supplied by DEC is inadequate. Brian points out that at the 
very low price for a complete machine, the PDP-8A/80Q with an FPP-8A should 
swell the ranks of FLAP users. 

Lars Palmer sent along information on the FPP Support Package. It is a sort 
of library in the form of a source file full of conditional assemblies that you 
assemble with your program. It contains the code to service the FPP, you can 
get buffered I/O support, I/O formatting and conversion, and a substantial col- 
lection of mathematical functions. Only what you ask for is included in your 
program. It looks like it has good potential in spite of the fact that it is 
almost unknown and DEC has given it almost no promotion, Brian Converse points 
out one question, however. The FORTRAN library appears to have been largely 
derived from this support package. It appears that as corrections tG the code 
in the FORTRAN library have been made that no retrofit to the FPP Support Package 
has been attempted. An outdated version seems to still be distributed. This 
would not be difficult to correct, however. 

Because the FPP Support Package is In source form it seems that integrating the 
FPP simulators from FORTRAN IV would not be hard. This will give a floating 
point package that is more powerful than the standard DEC software and which is 
upward compatible from the plain basic PDP-8 through 8e EAE to a full scale 
floating point hardware configuration. This package could even be the basis of 
a higher level language compiler (RALF and its loader would be nice if it did 
not presume the FORTRAN IV Run Time System) . If anyone is interested enough in 
this idea to put in some work helping refine what I have already done on it 
let me know. 

LINC Mode Under RTS-8 



Dr. Goetz Romahn has written to say he has modified RTS-8 to handle LINC mode 
interrupts. If you are interested you can contact him at: Heinrich-Hertz 
Institut, Einsteinufer 37, 1000 Berlin 10, Germany. 
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CCL MODIFICATION TO MAKE DEFAULT DEVICE DSK : 

The currently distributed versions of CCL force the default device to he the 
permanent device SYS: (i.e., internal device #1). If you would prefer DSK: 
to "be the default device consistent with the conventions in the rest of OS/8 
it is easy to change if you can settle for permanent device #2 (this will 
be DSK: if you use BUILD - otherwise use RESOkC with /E to check). Find 
the symobl NMOVE. A few locations later (depending on the version you have) you 
will find where a 1 is forced into the accumulator if no device has been 
specified. Just change that instruction to CLA CLL IAC RAL to force a 2 in- 
stead. Note that the USR is already in core during this routine so a slightly 
more complex patch could actually determine the device number for the device 
currently assigned the name "DSK" instead* This would allow you to use 
ASSIGN to temporarily re-assign the default device whenever you vrmt. 

DIRECT /A 



I recently incorporated some material into DIRECT that was circulated at the 
Fall DECUS Symposium. In particular I inserted the code to implement a /A 
option which causes the directory listing to be alphabetized (±x, overrides /E 
if both are given) while retaining all the other features of the V3C release. 
Unfortunately I am not sure who to give credit to for the cede I used as all 
identification seems to have been separated from it. I hope I can convince DEC 
to use this enhanced version of DIREC* 1 in future OS/8 releases but in the mean- 
time if anyone wants to try it out they should contact me. 

FORTRAN II USING THE FPP-12 

Hans W. Goebel is looking into trying to use the FPP-12 (or presumably the 
FPP-8A) with OS/8 FORTRAN II. If you would like to contact him, his address 
is: Purdue University, Properties Research Lab, School of Mechanical Engineer- 
ing, 2595 Yeager Road, West Lafayette, Indiana U7906. 

MICROPROCESSOR CROSS ASSEMBLERS 

I recently received a package of information from William Bonham of Sierra 
Digital Systems- It documents his "X8" line of microprocessor cross-assemblers 
that run on the 8 family under OS/8. The line presently covers the M.O.S. 
Technology 6502, Motorola 6800, and the Intel 8030. Bill plans to support the 
Signetics 2650 and the Fairchild F8 shortly. He is also looking into the 
possibilities for the 1*0^0, SC/MP, PACE, 1800, PPS-8 and CP1600. 

The X8 series are written in PDP-8 assembly language rather than FORTRAN so 
they run much faster on the 8, require less DEC software investment (i.e., 
no FORTRAN IV), and they all run in any 8K OS/8 sysu m. I hope those of you 
who use this software will contribute comparisons on the features and per- 
formance as they seem quite nice, but I do not have enough experience with 
microprocessor software to make a good judgment. 

The prices seem reasonable in comparison to the competition. Anyone who already 
has an OS/8 system or who is planning to dc extensive microprocessor software 
development should find the X8 series very cost effective compared to the 
typical time sharing costs I have heard of. The Bonhams are at lUUO West field 
Ave., Reno, Nevada 89509. 
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PATCH FOR FORTRAN IV 

Lars Palmer has forwarded a patch done "by A. Vindram. It is for PASS3.SV V3.03 
to correct some bugs and implement a /M option which causes only lines with 
errors to he listed. Because it may need to be modified for the new release of 
FORTRAN I will not publish it in this Newsletter, hut if anyone needs a copy 
write to me. 

NOTE FROM MIKE LOWCOCK 

Mike Lowcock and hike Humberston have written to say they have three systems 
developing RTS-8. They would like to hear from, others who have solved or have 
ideas of how to solve the restrictions of the OS/8 filing system, and support 
of the FPP (under FORTRAN IV) . They have developed a card reader drive for 
RTS-8. Until they decide to submit it to DECUS contact them at: Department 
of Economics, Alfred Marshall Building, University of Bristol, kO Berkeley 
Square, Bristol BS8 1HY, England. 

NOTE FROM STUART DOLE 

Stuart Dole has written about OS/8 BASIC. He comments on the problem of need- 
ing a symbol table to work with user functions. DEC usually fails to update 
published symbol tables when they release new versions of software. I think 
this is the case with BASIC and it is also true of updates to information pub- 
lished for OS/8 FORTRAN IV. He has written BASIC functic is for reading and 
writing random access files in 12 bit format. He also has included some use- 
ful TECO macros and patches that I will try to include. His address is: 
c/o Anesthesiology Research, 1386 HSE, U.S. Medical Center, San Francisco, 
CA 9^3. 

MATERIAL FROM STEVE L1QETT 

Steve (formerly with DEC, now at Dartmouth) has sent along a number of interest- 
ing items. Among them are an article on OS/8 Bootstraps, BATCH log on the LA- 36, 
a BASIC Margin Function, and several patches for DIRECT. I will include all 
of them that will reproduce. For any that don't reproduce, plus some trial code 
to use the type ahead buffer in RTS-8 to bring up OS/8 with commands in the 
buffer contact me. 



From MAURICE KENNEAUY (EDUCOMP) #16 8. 

REVIEW OF EDUCOMP'S TIMESHARED OPERATING SYSTEM 



EDUCOMP's ETOS makes available a 32K virtual OS/8 system to each of 
many simultaneous on-line users. It will handle interactive, batch 
and real -time tasks. Peripherals currently supported by the ETOS 
monitor are the extended arithmetic element, line printer, card 
readers, Dectape, high speed paper tape reader, high speed paper tape 
punch and a variety of terminals. 

For devices ETOS does not support, EDUCOMP has devised a unique plan 
for implementation. Device handlers may be run as detached user jobs. 
Users who desire to utilize the device send che job a message concern- 
ing the respective user task. This method has the advantage of 
separating the monitor and the device handlers. Users can debug their 
handlers external to ETOS. Therefore, ETOS can be more easily and 
satisfactorily supported, and modularity is maintained. Documentation 
is provided for the writing of device handlers and hooking these jobs 
into the ETOS interrupt skip chain. Because the detached task 1s hooked 
into ETOS in this manner, the unusual peripheral can be supported as 
efficiently as a standard peripheral and timesharing need not be 
noticeably affected. 

The real-time support may also be used in conjunction with the device 
support. The user has the facility under ETOS to lock his job into 
core for a specified period of time. During this period, he may or 
may not decide to service interrupts. The user can actually program 
most real-time applications so that other timesharing usei*s are unaware 
of the real-time processing. This capability will allow analog to 
digital conversion, digital to analog conversion, and simulation of 
events taking place in a critical period of time. 

When ETOS is running, most processes are in user mode. This mode of 
operation causes the hardware to trap all Input/Output instructions, 
which include instructions that load and read the IF and DF registers. 
When the user executes a field instruction, the monitor maps the 
virtual address (the field specified in the change field instruction) 
into a physical address space. If the field which the user desires to 
access is not resident, the monitor must swap into memory an iiege of 
this field stored on the disk. This mapping procedure is transparent 
to the user. He programs as if he had a real 32K word machine to 
himself. 

To speed up the mapping process, EDUCOMP designed a timeshare control 
module. This module plugs into the omnibus like any other PDP8 module. 
The difficulty that this option overcomes occurs in the case of the 
Change Instruction Field (CIF) instruction. When this instruction is 
executed, it does not «,ake effect until the next JMP or JMS instruction, 
thus making cross-field subroutine calls possible. As a /-esult, when it 
gets the CIF instruction, the timesharing monitor may only note the fact 
that a change is pending. As no monitor trap is causeu oy the OMP or 
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JMS, either the monitor would have to emulate all instructions from the 
CIF to the next JMP or JMS, or a hardware unit must trap JMP or JMS when 
it is enabled. EDUCOMP chose the latter course because of its greater 
efficiency. It is important to note that a computer with this additional 
module operates normally when the user processes stand-alone. 

In addition to multi-user OS/8 capabilities, the ETOS user has the 
facility to enter the System Command and Login/Logout Executive (SCALE). 
This provides each user with absolute control facilities over his virtual 
machine. In essence, the user has a virtual front panel. All virtual 
registers can be displayed and modified. Virtual memory locations may 
also be examined or changed. This provides a powerful debugging tool 
for Assembly language programs. If the user's program halts or he 
destroys his copy of OS/8, no other users are affected, and the virtual 
machine with virtual OS/8 may be restarted from the terminal with a BOOT 
command. 

File security and selective information-sharing have also been the subject 
of a great amount of development effort. A password and an account number 
must be specified to allow access to system resources. If the password 
or account number does not match a table of valid accounts set up by the 
system manager, entry to the system is denied. 

Each account nunfcer has a set of attributes assigned to it by the manager. 
A file quota may be imposed to limit the amount of storage available to 
an account. Users can thus be inhibited from inadvertently or inten- 
tionally filling up the public disk structure. A user's files are, in 
addition, stored with a protection code which allows or disallows read/ 
write privileges on those files of users under other accounts. Multiple 
users can, if the file protection code permits, read the same file 
simultaneously. An account may allow a user to mount his own private pack 
to extend his available storage area. Such private packs may be either 
totally private (single-user access only) or semi -private (accommodating 
more than one account). 

In addition to the capabilities available to all users, there exists a 
variety of features which the system manager may utilize to effectively 
control the system processing. The manager can assign different priorities 
and different quanta for user tasks. The maximum amount of core for a 
user may also be restricted. Job accounting may be used in conjunction 
with system features such as line printer spooling to increase system 
throughput. 

ETOS was developed by the EDUCOMP Corporation, 196 Trumbull Street, 
Hartford, Connecticut 06103. 



From IAN TEMPLETON (NATIONAL RESEARCH COUNCIL-CANADA) #16 10. 



Operation of FRTS and BASIC with a non-TD8E 2-page System Handler 

We are running OS/8 with a single floppy disk (Sykes) as the 
system device. To increase disk capacity (and incidentally to improve 
speed) we are packing four 12-bit words into six 8-bit bytes, and this 
extra complexity necessitates the use of a 2-page system handler. 

Such a system runs into complications with FRTS and BASIC, since 
both these programs shift various areas of core around, and are 
programmed to take special care of the second page of the system 
handler only if the TD8E handler is recognized. 

I have identified the locations involved in the recognition and 
special action, and it seems worthwhile to moke this information 
available to other users who may run into similar problems. 

1 . FRTS 

The TD8E handler is recognized by examination of the content of 
the field address stored at 12757- At present 12757 contains the 
address 7642, and the TD8E handler contains 6223 (CIF CDF 20) at 
this address. If the content of this address is 62x3 (bits 6-8 are 
masked out), the addition of 1575 contained in 12755 gives zero, and 
this initiates the special action. 

A subroutine at 17526 changes three field 2 instructions in page 1 
of the handler to field H (max), and the second page of the handler is 
shifted to the top of core. The non-zero content of 12703 following 
this action ensures that a subsequent transfer of 3000 words is made 
into 46C0-7577 of field M rather than into 5000-7777 . 

On completion of the run, the second page of the handler is 
returned to field 2 and the field instructions are rewritten by 
the same subroutine as before. 

In the special case of a 12K system, where M=2, the only action 
necessary is to place some arbitrary non-zero instruction (e.g. HLT, 7^02) 
in 12703. This ensures that the second page of the handler will not be 
overwritten. In the more general case, however, the address at 12757 
and the two's complement of its (masked) content at 12755 must be 
modified to correspond with tne new handler, and the instruction-changing 
subroutine must be altered. Initial entry to the subroutine occurs 
with DF=*0 and 62M2 in the AC, following a TAD (CDF MAX) at 12675 and 
an IAC at 12676. The reverse change occurs at 17^16 where the content 
of 17576 (currently 6222) is loaded before calling the subroutine. 
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A listing of the subroutine is given below. In general the 
modifications required will be trivial. In our case it is mere 
convenient to enter with a CDF instruction in the AC, hence the I AC 
at 12676 is changed to a NOP. and the 6222 at 17576 is changed to 
6221. The three addresses at 17561-3 have to be altered to those 
appropriate to the new handler. 

2. BASIC 



The approach here is somewhat similar, except that BLOAO.SV tests 
in three places whether TD8E is the system device by examining the 
first word in the device control word table. Bits 0-2 and 5M1 are 
masked out, and 7570 (2*s complement of 0210, since the TD8E device 
code is 21) is added. Locations 567, 2561 and 7374 of BtOAD.SV must 
be changed to contain the 2's complement of 0NN0, where NN is the new 
system device code. 

If TD8E is found to be the system device, BLOAD then tests in 
addition that the content of 7642 is 6223. Locations 566, 2560 and 
7373 contain the address 7642, and 565, 2557 ana 7372 contain 1555, 
the 2's complement of 6223. 

The field instruction changes are done by one or other of 
routines which start at 500 and 7256 and, as before, deposit 62x3 
in 7642, and 62x2 in 7721 and 7727. Restoration is done by the same 
routines but an alternative restoration routine, which appears to be 
used in some circumstances, exists in the BASIC.FF overlay. This 
starts at 14561, and simply places a 6223 from 14573 in the address 
contained in 14574 (7642), and a 6222 from 14575 in the addresses 
contained in 14576 and 7 (7620 and 7655). 

With appropriate patches in these locations BASIC runs, and 
returns to OS/8, as expected, but I cannot guarantee to have found 
ai! the problem areas! 
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&pr$as I am) with PDP-3 high-level string h 

Apropos of nothing much, has anyone given t 
mand for calling non-Command Decoder progra 
when filnam is a .SV on SYSs to £• chained 
characters to be placed in the Decoder's ou 
a word. Currently only TECO and CCL itself 
ever, if it were generally available, user 
modified to use it. In the latter category 
FOCAL and PS/8 LISB, neither of which may n 
noninteractive jobs due to their total terra 



•iai compiler for OS/6. The 

SHOBOL I? , with modifications 

■ including device independence 

package is rather unusual in 

the Monitor; sections loaded 

i locks and loaded as overlays; 

iarts shared with the compiler 

The compiler is unusual 
la IBM 360 WATPOH and producing 
jig and documentation are com — 
>e done (alas'). Any infor- 
iated from anyone who is fed 
mdling. 

ought to some sort of CCL coa- 
s? I propose .DO filnam arg 
o, and arg is a string of 

:put buffer, one character to 
use this sort of call; how- 

>rograms might be written or 
I think particularly of Tj/W 

>w be called by BATCH even for 

mal orientation. Comments? 
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PDP8 SOFTWARE PLUMB 

Submitted by E. Lo pes Cardoso 

I would like to maze a few remarks on possible software 
developments for tie PDP8. 

To start with the operating systems, I see the following 
deficiencies in OS/8 (in order of importance): 

1. single-user onl;r 

2. cannot support arge file structured devices 

3. does not allow ml tiple open output files in a single directory 

4. restricted to 1;i devices (device-units!) 

5. filestructure d;>es not allow realtime file acces by independent 
processes 

One could Imagine a project to extend the BSS/8 background to a time- 
sharing system. Unfortunately, BTS/8 is not well suited for such 
operations, for instance because the scheduling strategy does not 
allow re-entrant t isks. Anyhow, such a project would be wastage 
as there are at le ist two OS/8- timesharing packages available 
from aother source i (MDLTI8 and ETOS). 

It should be possible to rebuild the file-managing part of OS/8 
to aleviate problem 2-3* Such a system would have "channels n much 
like BT/1 1 , each 'channel being associated with a file on a certain 
device. In that ca>e a file can be up to 4096 blocks long, and, 
provided the directory structure allows it, very large devices 
could be supported., 

Most of the CUSPS would have to be changed very little, only PIP, 
FOXP and DIRECT art? really sensitive. Such developments are 
largely dependent on future hardware policies. 
One might think of large disk drives (BP03 etc.) and a "memory 
management" option, doing things like field relocation, untrapped 
execution of CSF in User Mode, etc. A proper kind of hardware 
protection unit fo: * the SEP is another one. 

In the languages ai.-ea I would like two things s 

1. a relocatable-mi ,cro assambler (MICHEL) 

2. a really good implemented high level language. 

Currently we have BASIC (well implemented, but an awfull language 
to program), FOBTBJUJ II (spoiled by SABB) and POBERAH 17 (I cannot 
be enthousiastic al out integers that are managed am if they were 
reals). She new lax guage should preferably have the possibility to 
specify in the souxce whether a certain integer should be 12 or 24 
bits. One might think of PASCAL or a subset of ALGOL 68. But periaps 
a working MACBEL will open the door to an improvement of FORTRAN II. 

Concluding I would vote for the MACBEL project. I think it is the 
one that affects mcst of the users and could have a far reaching 
effect on other software projects as well. 
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STANDARD IOT-COBBS FOR PCBEGROTJBD/BACKGROUIID SYSTEMS 

Submitted by E. Lopes Cardozo 

The following is another proposal for the standardisation of IOT-codes 
used in foreground/background systems. It is largely based on the 
HULTI-8 system. She general idea is to differentiate between three 
types of IQT's: 

1. JOT* 8 that can be and mostly are truly emulated. Among these 
the CBR terminal IOT's, etc. 

2. IOT's that cannot be emulated, but may be expected to occur 
in some programs. 

5. XOT's that should not occur in normal PDP8-programs and get 
a special weaning assigned by the monitor system. 

To ensure the utmost compatibility with e.g. regular 0S/.8 user 

programs I propose to keep group 3 as small as possible. 

Many installations hare non-standard interfaces to all sorts of 

application-dependent devices. Some of these can be serviced 

by a fairly simple IOT-emulator that just executes the trapped IOT. 

Such applications should not get into conflict with some funny 

monitor, IOT. 

On the other hand group 3 should be large and flexible enough to 

implement any local specialties. In our MOLTI-8 system a number 

of important functions are activated via special IOT's: 

- an analog sample task that samples a given number of channels with 
given frequency and writes fe* rata to an user-defined diskfile. 

- a task that supports a so called 200 User Terminal (remote batch) 
communications line with vox university's CYBER 73. 

- various simple things like digital I/O etc. 

The solution to these apparently conflicting needs is to designate 
one IOT (in MULTI8 called the GIAHT IOT) and encode all functions 
in the users AC, This opens the door to 4096 unique monitor functions. 
For some reason our GTAT IOT has code 6770, but that is not pai't of 
my proposal here. 

I have objections to pionitrr functions line KSE (read Keyboard String) 
and SIS (Send A String;. 1 think the multi-user systems should be 
kept as much compatible with regular OS/8 as is possible. I do not 
think extensions like these do increase system performance noticable. 

For reference I include a copy of the MULTI8 IOT list. As you can 
see the number of monitor functions is very modest. Almost everything 
(like device- sharing) is fully automatic and unncticable. 
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— HJLTlQ terminal annual - 



IOC-list for MLFLTI8 background 

6000 Call block driver emulator, used hy the fakehandler to 
pass parameters from a handler call to the forground. 

TkD (OOKJ /D-DEVICB TYPE, U-UNIT 

6000 

JME* .A /Jt*f> OVER PARAMETERS 

F OICTI ON /JUST LIKE OS/8 HANDLER CALL 

BUFFER / 

BLOCK / 

RETORlf /AOO OR ^000 ( "ERROR ) 

6001 I0«; Invalid instruction for MULTI8 

5002 ICF; A no-op for MJUSUB 

6003- Error 
600$ 

6006 SOT; If EAE is present, Skip on Greater-Than flag 

600?— Error 
6200 

601X Reader IQT's 

602X Puncher IOP's 

6Q3X Keyboard ICT'S 

6CkX TKTJ3PRIHIER IOT's. 6<Ul will always skip. 

621T1 CDF N; Change data field to field If if field If is 
available; Otherwise no-op. 

62H2 CIF If; Change instruction field to If id field If is 
availble; Otherwise no-op 

6216 CDF CW n 

6&k SMB; Skip-on-MC&TlS 

626k Ixx>k-into-forgraund; Delivers a word from the foreground 
memory into the users AC. This I0T should be followed 
by a CDF to the real field that must be looked 
into. The address within that field is specified in 
the AC. 

666K Lineprinter IGT's. 6661 is changed to SKP. 

IOT-iist-1 
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The log program has two main functions: 

(a) To log users on and off the machine. The user uses the program 
through CCL calls LOG ON and LOG OFF and the program maintains a 
file containing details of the user's initials, department, date 
and time- KK5 changes tne resident monitor coding such that the 
next jump to 7600 after LOG OFF will automatically recall the log 
program for the next user. 

(b) To allow each user access to his own disk partition. 

In order to avoid directory overflow problems on our RK8E we have 
split the disk into a number of files (known as .SY files) and 
each file may be used as a separate device w ith its own directory. 
The log program asks the user which file is required, does a look- 
up on the file and sets up parameters in a special 2-page handler, 
MOLT. MOLT is not a true device handler in that it must use another 
handler to actually perform the transfer. Usually this is the 
resident SYS or BKB0 but it can be a non-resident handler in which 
case the required handler is held in the empty second page. MOLT has 
up to eight entry points LSK0-7 and therefore up to eight files may 
be 'logged on* to at any one time. In our system DSK0, the default 
entry to MOLT, is assigned as DSK, and each user once he has logged 
on is usually only aware of SYS, holding F*f etc., and his own programs 
on DSK. 

Block of every .SY file may be used, if required, to hold a 
password to ensure only authorized access to that file, a list of 
authorized users against which the users initials are checked and 
the option to set MOLT, for that DSK, to read only. 

The log program also contains a number of •maintenance* routines. 
For example, creating .SY files and examining the log data. These 
routines allow the user to readily set up and check the system. 
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SPR #8-1893 BUG IN OS/8 V3C RELEASE OF BLOAD 



PROBLEM: WHENEVER BASIC OR BCOMP COMPILES H PROGRAM WITH ERRORS 
ON A MACHINE THAT HAS THE SOFTWARE CORE SIZE SET, LOCATION O7600 
IS CHANGED TO RN INCORRECT VALUE WHICH LATER CRASHES THE SYSTEM- 
RESOLUTION: THE PROBLEM IS CAUSED BV AN ERROR IN BLOAD AT THE 
POINT WERE IT RESTORES 07S®1d TO THE NORMAL VALUE. WHEN THE 
SOFTWARE CORE SIZE WORD IS NON-ZERO AN INCORRECT VALUE IS 
RESTORED. THE FOLLOWING PATCH CORRECTS THE PROBLEM. 



. GET SVS : BLOAD 


. ODT 






2315/ 


1371 


5363 


2363/ 


XXXX 


7280 


2364/ 


XXXX 


1371 


2365/ 


XXXX 


5316 


3030/ 


0140 


0240 


~C 






. SAVE 


SVS: 


BLOAD 



THIS PATCH UPGRADES BLOAD FROM V4A TO V4B. 

TECO PATCHES FROM STUART DOLE 

1331/4515 5214 < KILLS ECHO OF ~T COMMAND > 

1332/1035 1037 <SET VALUE OF EOF FLAG; IF EOF> 

3764/XXXX 3824; <CHAR TVPEOUT - KILL NUMBER FLAO 

1027; CGET ARGUMENT > 

4515; <TVPE IT> 

5586 <POPJ - RETURN > 

5002/0011 1332 <"B COMMAND - VALUE OF EOF FLAG - 

4095 IF FILE OPEN, 8 IF EOF SEEN> 

5126/0011 3764 <V COMMAND - COULD BE ANV OTHER CHRR 

WITH 8011 VALUE. TVPE ARG AS ASCII ON 
CONSOLE > 

THESE ALLOW THINGS LIKE: <PB; >$* - EMPTV INPUT FILE, BRANCH OUT ON 
EOF. THE ECHO ON THE ~T IS A BOTHER WHEN WRITING INTERACTIVE 
MACROS.. IE: A MA_RO TO GO THROUGH AN UNCOMMENTED SOURCE FILE AND 
ALLOW EASV INSERTION OF COMMENTS: 

!A! 

L 2R OT 

!B! 

~T VA 

QA-13 H E L 0A$' 

QA-127 "E R 0AV D OB$' 

QA V 

QA I $ 

OB* 

STUART NOTES HE HAS A BETTER EXAMPLE THAT DOES LINE EDITING LIKE 



FOC*L. #16 W ' 

HE ALSO NOTES TROUBLE WITH THE BCOMP /K SWITCH SEVERAL OTHERS 
HflVE RLSO. I AM WAITING TO SEE IF THE RECENTLY PUBLISHED PATCHES 
FIX THE TROUBLE AND IF IT HAS BEEN FIXED IN THE NEW RELEASE BEFORE 
PRINTING ANV MORE ON THE SUBJECT. 



PATCHES FOR DIRECT <0S/8 V3, V3B, V3C> FROM STEVE LIGETT 

1. ALLOWS =N OPTION IN RANGE OF 8 TO 13 
12171/7770 7765 

2. SQUISHES DIRECTORY TOGETHER ON A LISTING 

13160/0005 0003 

13750/0005 0003 

3. REMOVES LENGTHS OF EMPTIES FROM /E/F 

13712/6201 1767 

13713 /1426 0374 

13714 /6211 7640 

13715 /7041 5325 

13716 Z4754 6201 

13717 Z2753 1426 

13720 Z5325 ^211 

13721 Z4752 7041 

13722 /1751 4754 

13723 Z3753 1347 

13724 /5641 4763 

13725 /1350 2753 

13726 Z4763 5333 

13727 /1767 4752 

13730 Z0374 1751 

13731 Z7640 3753 

13732 Z5641 5641 

13733 Z1347 1350 

13734 Z4763 4763 

4. CHANGE DEFAULT NUMBER OF COLUMNS =N TO =3 

12305/7040 1747 

12306 Z1747 745© 

12307 Z750& 7125 
12310 Z7040 7041 

AN OS/8 BASIC MARGIN FUNCTION FROM STEVE LIGETT 

PROBLEM: USERS OFTEN WANT TO CREATE FILES OR TERMINAL OUTPUT WITH 
A RECORD LENGTH GREATER THAN 72 CHARACTERS. 

DISPOSITION: SUPPLIED HERE IS A MARGIN FUNCTION <MRR> THAT CAN BE 
INSTALLED IN THE BASIC USER FUNCTION OVERLAV "BASIC. UF". A CALL 
TO THIS FUNCTION ALLOWS A USER TO USE DIFFRENT RECORD LENGTHS IN 
DIFFRENT PROGRAMS, AND TO CHANGE WITHIN A PROGRAM. 

STEP 1. INSTALL THE FOLLOWING PATCH TO BRTS, 



GET SVS: BRTS 



#16 



20. 



. ODT 

2456/1343 1713 
2513/7678 3252 
2533/1368 1573 
92:j?4 /3014 1361 
G2a 5 /1573 7518 

02536 /1414 5347 

02537 /7510 7450 

02540 Z5347 5513 

02541 Z7650 2007 

02542 /5513 5334 
Q2543 Z2007 7200 
02544 Z5335 7000 



2566/7774 
3252/7670 



7770 
7600 



. SflVE SYf . BRTS 



THIS SETS BRTS UP TO USE 3 
(LOCATIONS 2566 AND 3252>. 



COLUMNS, 128 CHARACTERS PER RECORD 



STEP 2. CREATE THE FOLLOWING FUNCTION. THIS CAN BE ORIGINED TO 
3400, IF IT IS THE ONLY USER FUNCTION NEEDED, OR IT CAN BE ADDED 
TO OTHER FUNCTIONS THE USER HAS WRITTEN. 

/MARGIN FUNCTION FOR OS/8 BASIC 



ORG=3400 


/OR AN 




♦ORG 




MAR, 









JMS I 


INTL 




CIA 






DCA I 


LWIDTH 




TAD 


D14 




JMS I 


MPV 




STA 






TAD 


TEMP6 




DCA I 


MCOMMA 




JMP I 


MAR 


LWIDTH, 


3252 




MCOMMA, 


2566 




D14, 


445 




TEMP6=50 




MPV=121 






INTL=la.4 





/OR ANYWHERE WITHIN THE USER FUNCTION AREA 



/MARGIN UDEF 

/FIX ARGUMENT 

/NEGATE 

/AND STORE 

/DIVIDE BV 14 FACTOR 

/MULTIPLY 

/LOAD A -1 

/HIGH ORDER PRODUCT-* OF COLUMN* 

/STORE AS COMMA COUNT 

/RETURN 

/ADDRESS OF -LINE WIDTH 

/ADDRESS OF # OF COLUMNS <-!> 

/ 4096/14 

/TEMP AREA USED IN MPV 
/POINTER TO MPV 
/POINTER TO FIX RTN 



STEP 3. RENAME THE LAB 8/E FUNCTIONS TO SOMETHING OTHER THfiN 
"BASIC. UF"; ASSEMBLE THE FUNCTION; RND CREATE THE USER OVERLAY 



RENAME BASIC. LF<BASIC. UF 

PAL MARGIN<MflRGIN 

LOAD MARGIN 

SflVE SYS: BASIC. UF 3400-4577 



STEP 4. 
6-125 >. 



INSERT THE ENTRY POINT INTO BRTS COS/8 HANDBOOK, 
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PAGE 



. GET SVS: BRTS 

. ODT 

±560/8240 3400 



. SAVE SVS; BRTS 

STEP 5. TEST THE FUNCTION. THE FOLLOWING PROGRAM DEMONSTRATES 
THE USE RND ACTION OF THE "MAR" FUNCTION. 



. R BRSIC 






NEW OR OLD — NEW MRRTST 


READV 






100 UDEF MAR<D) 


i 




110 PRINT "ENTER TERMINAL WIDTHS 


120 INPUT W 






120 FOR M « 14 


TO W 


STEP 14 


140 D = MAR<M> 




150 C = M / 


14 




160 FOR N = 


1 TO 


C 


170 PRINT N, 




180 NEXT 


N 




190 PRINT 0; 


"< — 1 


RETURN" 


209 NEXT M 






210 FOR M = 4 TO W 




200 D = MAR<M> 




230 PRINT M; 






240 NEXT M 






250 PRINT 






260 GOTO 110 






939 END 






RUN 




- 


MRRTST BR 4R 


10-MRR-76 . 


ENTER TERMINRL 


WIDTH784 


1 






< — RETURN 






1 


2 




O < — RETURN 






1 


2 


3 


< — RETURN 






a 


2 


3 


< — RETURN 






1 


2 


3 


< — RETURN 






1 


2 


3 


< — RETURN 






4 






5 6 






7 8 9 






10 11 12 
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13 


14 


15 


16 


























17 


18 


19 


20 


21 
























22 


23 


24 


25 


26 


27 


28 




















29 


38 


31 


32 


33 


34 


35 


36 


37 
















38 


39 


40 


41 


42 


43 


44 


45 


46 


47 


48 


49 










58 


51 


52 


53 


54 


55 


56 


57 


53 


59 


60 


61 


62 


63 


64 


65 


<So 


67 


68 


69 


70 


71 


72 


73 


74 


75 


76 


77 


78 


79 


80 


81 


ENTE 


R TERMINAL WIDTH?~C 






















READY 






























BVE 
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NOTE ON OS/8 SYSTEM BOOTSTRRP FROM STEVE LIGLTT 

ADEQUATE EXPLANATION AND DOCUMENTATION EXIST IN THE QS/8 HANDBOOK 
<CDEC-S8-0SHBA-A-D>, AND THE OS/8 SOFTWARE SUPPORT MANUAL 
<DEC-S8-OSSMB-A-D>, AND THE KL8E SOURCES TO ENABLE ONE TO WRITE AN 
OS/8 NON-SYSTEM HANDLER. IN ATTEMPTING TO WRITE A SYSTEM HANDLER, 
HOWEVER, WE FIND A CRUCIAL PIECE OF INFORMATION IS MISSING: WHAT 
DOES A BOOTSTRAP LOOK LIKE, AND WHAT DOES IT DO? 

THERE ARE TWO BOOTSTRAPS FOR EACH DEVICE: THE PRIMARY BOOTSTRAP 
THhT IS TOGGLED IN, AND THE SECONDARY BOOTSTRAP THRT IS CODED WITH 
THE SYS1!£M HANDLER. THE PRIMARY BOOTSTRAP IS WRITTEN TO BE AS EASY 
TO ENTER AS POSSIBLE AND MOST OF THE WORK IS GENERALLY LEFT TO THE 
SECONDARY BOOTSTRAP. WERE ARE EXPLANATIONS OF THE BOOTSTRAPS FOR A 
ONE PACT OR A TWO PAGE SYSTEM HANDLER. 

FOR A ONE PAGE HANDLER, BLOCK OF THE SYSTEM CONTAINS: 

BLOCK 8 <ADDRESSES REFER TO RESIDENT MONITOR LOCATIONS> 



!1 




l'l 




1!8 


!7 




7!7 




7!7 


•6 


SECONDARY 


6!6 


FIELD 1 


7!6 


!0 


BOOTSTRAP 


4!4 


RESIDENT 


7!6 


!0 




S\7 


MONITOR 


7!0 



O! 

7! 
FIELD © 7! 

RESIDENT MONITOR 71 



7! 



PAGE 1 PAGE 2 

THE PRIMARY BOOTSTRAP READS BLOCK 8, WHICH INCLUDES THE SECONDARY 
BOOTSTRAP. THE SECONDARY BOOTSTRAP MUST FIT WITHIN THE COMMAND 
DECODER TRJLE AREA AND MUST BE 47 <OCTAL> LOCATIONS OR LESS. THE 
BOOTSTRAP MUST ALSO BE AT LEAST 21 < OCTAL" LOCATIONS. BLOCK ALSO 
INCLUDES THE COMPLETE RESIDENT OS/8 MONITOR AS SHOWN ABOVE. THE 
SECONDARY BOOTSTRAP MOVES THE FIRST PAGE TO THE TOP OF FIELD 1 AND 
MOVES THE SECOND PAGE TO THE TOP OF FIELD 0. THEN THE BOOTSTRAP 
BRANCHES TO LOCATION 0760?, THE DESTRUCTIVE ENTRY TO OS/8. 
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FOR fl TWO PAGE HANDLER, BLOCK 8 CONTAINS: 
BLOCK 8 



SECONDARY BOOTSTRAP 



!0 
I? 
!6 
!8 
!0 



FIELD 8 
RESIDENT MONITOR 



0! 
7! 
7! 
7! 
7! 



PAGE 1. 



PAGE 2 



IN ADDITION, THE CONTENTS OF BLOCK 66 <OCTAL> ARE DEFINED 



!± 
!7 
!6 
!0 
'.0 



BLOCK 66 



FIELD ± 
RESIDENT MONITOR 



±!2 
7!7 
7«6 
7!0 
7!8 



FIELD 2 
RESIDENT MONITOR 



2! 
7! 
7! 
7! 
7« 



PAGE 1 



PAGE 2 



THE PRIMARY BOOTSTRAP READS BLOCK 0, INCLUDING THE SECONDARY 
BOOTSTRAP. THE SECONDARY BOOTSTRAP OCCUPIES THE ENTIRE FIRST PAGE 
OF BLOCK 0. THE SECOND PAGE CONTAINS THE FIELD RESIDENT 
MONITOR. THE SECONDARY BOOTSTRAP READS BLOCK 66 <OCTAL>. THIS 
CONTAINS RESIDENT PORTIONS OF THE MONITOR FOR FIELDS 1 AND 2. THE 
BOOTSTRAP THEN MOVES ALL THREE PAGES OF THE RESIDENT MONITOR TO 
THE TOP OF THE PROPER FIELDS AND BRANCHES TO LOCATION 07605. 



NOTE ON BATCH LOG ON LA-36 FROM STEVE LIGETT 

PROBLEM: OS/8 BATCH NORMALLY OUTPUTS A LOG TO THE LINEPRINTER 
I .NG AN INTERNAL LINEPRINTER HANDLER. INITIALIZATION CODE 
DETERMINES WHETHER OR NOT A LINEPRINTER EXISTS. THIS CODE WILL NOT 
REC0GNI2E A SLOW <TERMINAL> DEVICE AS A LINEPRINTER. USERS WITA 
"CLASSIC" TYPE CONFIGURATIONS OFTEN HAVE AN LA-36 FOR A 
LINEPRINTER AND HAY WANT TO USE IT FOR THE BATCH LOa 

DISPOSITION: THE FOLLOWING PATCH CAUSES PPSTCH TO ASSUME THAT A 
LINEPRINTER EXISTS. THE /T SWITCH MAY BF USED TO DIRECT THE LOG TO 
THE TERMINAL. 

NOTE: IF THE LINEPRINTER IS ATTACHED VIA A SERIAL INTERFACE, BATCH 
»^iILL BE UNABLE TO DETERMINE IT IS OFFLINE. 

. GET SYS: BATCH 

. ODT 

310/5320 7000 

~C 

. SAVE SYS : BATCH 

TO USE A DEVICE OTHER THAN €6 AS THE LINEPRINTER, INSTALL THE 
FOLLOWING PATCH. 

. GET SYS: BATCH 

. ODT 
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6526/6666 6XX6 

652±/666± 6XX± 

. SAVE SVS: BATCH 

INSERT THE DEVICE CODE OF THE DESIRED DEVICE IN PLACE OF XX ABOVE 
<E a , XX=84 WILL OUTPUT THE LOG ON THE CONSOLE). 



NOTE ABOUT BAT: FROM LARS PALMER 

AS VOU PROBABLV KNOW THERE AIRE TWO "SPECIAL" HANDLERS IN THE QS/8 
SYSTEM, THE "BAT" AND "NULL" HANDLERS. THE "NULL" HANDLER UA5 
DRAWN ATTENTION TO IN THE DIGITAL SOFTWARE NEWS RECENTLY BUT THIE 
"BAT" HANDLER HAS BEEN DISCUSSED VERV LITTLE. THE OS/ i 
DOCUMENTATION SAYS THAT IT CAN ONLY BE USED IN THE NCN FILE 
STRUCTURED BATCH INPUT DEVICE BUT THIS IS NOT TRUE. ANY PROGRAM 
THAT DOES NOT TOUCH THE BATCH FIELD MAY CRLL THE "BAT" HANDLER 
WITHOUT RESTRICTIONS. FORTRAN IV AND BASIC ARE DIFFICULT AS THEY 
CREATE HAVOC IN THE BATCH FIELD. IF YOU CAN AFFORD TO RESERVE 
SPACE IN CORE TO LEAVE THE BATCH MONITOR UNDISTURBED WHEN USING 
FORTRAN IV THE FOLLOWING SMALL PATCH TO THE RUN TIME SYSTEM 
PRESERVES BATCH <NOTE THAT WITH THE LOGIC IN FRTS THE SAME 
CONSERVATION OF CORE WILL BE DONE AS FOR AN IN-CORE TD8E SYSTEMX 
CHANGE LOCATION ±2744 TO 2080 <WAS 4600) AND CHANGE LOCATION ±2745 
TO 30O0 <WAS 280X 

<NOTE: I HAVE TESTED THIS WITH THE V3C RELEASE OF FORTRAN IV <V4> 
AND IT SEEMS TO WORK OK - RH> 



